When data is delivered in packets to a plurality of terminals over a network, the flow of data to transmit needs to be controlled according to the conditions of the network and receiving terminals.
Especially, when delivering data over the Internet, it is necessary to impartially share the bands with other traffic other than video and audio data on the Internet. Most of other traffic on the Internet is traffic using TCP (Transport Control Protocol). For this reason, it is well settled that fairly sharing the band with other traffic on the Internet may be realized through flow control so that the band is shared fair with traffic using TCP. That is, it is well settled that flow control having good affinity with TCP is best to be performed when delivering data over the Internet.
Meanwhile, when data is delivered to a plurality of terminals, it is possible that the terminals have different capacities. To be more specific, while the speed of only several Mbps (megabits per second) is allowable to terminals connected to the Internet via ADSL (Asymmetric Digital Subscriber Line), terminals connected to the Internet via optical fiber can deliver data at a speed of 100 Mbps. When data delivery is performed simultaneously to terminals connected to the Internet via ADSL and terminals connected to the Internet via optical fiber, a scheme of performing flow control such that data is delivered at a speed not exceeding the speed allowable to the slowest terminal, that is, a terminal connected via ADSL, is known. To be more specific, for example, a flow control scheme using TFMCC (TCP Friendly Multicast Congestion Control) is known.
However, with these schemes, when there are receiving terminals of various speeds, receiving terminals having high capacity cannot receive sufficient data delivery. Referring back to the aforementioned example, although a terminal that is connected via optical fiber has a receiving capacity of 100 Mbps, the terminal can receive data delivery only at several Mbps. Such a situation produces unfairness in the same session (i.e. data delivery) and is referred to as “intra-session unfairness.” Therefore, the flow control scheme for delivering data to a plurality of terminals is expected to be able to realize a state in which all receiving terminals can receive data at their maximum capacities, that is, maintain fairness in sessions and resolve intra-session unfairness.
The SICC (Sender Initiated Congestion Control) scheme is known as a flow control scheme for resolving intra-session unfairness while keeping affinity with TCP (e.g. see Non-Patent Document 1).
Furthermore, the TFRC (TCP Friendly Rate Control) scheme is known as a scheme for estimating the rate at which data can be transmitted (e.g. see Non-Patent Document 2).
The SICC scheme is a transmission scheme for realizing flow control using this TFRC scheme in a type of multicast-based communication in which a transmitting terminal explicitly specifies a list of destination addresses of receiving terminals such as an XCAST (eXplicit Multicast) scheme.
Here, the SICC scheme will be explained in detail.
SICC-based transmitting terminals have a plurality of classes sending packets at different rates. The transmitting terminal estimates the rates data can be transmitted to the receiving terminals, based on the TFRC scheme, and classifies the individual receiving terminals into the above-described plurality of appropriate classes, based on the estimated values. The transmitting terminal delivers XCAST packets, in which the addresses of the receiving terminals classified into classes are specified.
A transmittable rate is estimated based on feedback from a receiving terminal about a round trip time (RTT) of a packet between a transmitting terminal and the receiving terminal. This transmittable rate is estimated based on the TFRC scheme, which is a scheme that fulfills affinity with TCP. Therefore, the flow control exercised by the SICC scheme fulfills affinity with TCP.
By the SICC scheme, transmittable rates are estimated based on the TFRC scheme and the receiving terminals are classified into appropriate classes based on the estimated transmittable rates. Therefore, by the SICC scheme, it is possible to drastically improve fairness within a session while fulfilling affinity with TCP without the speed being limited by a receiving terminal having the lowest transmittable rate during delivery of a packet.
By the way, measuring RTTs is indispensable to the estimation of transmittable rates by the TFRC scheme as described above. With the TFRC scheme, a transmittable rate Xcal is estimated based on following equation 1.
[1]
                    Xcal        =                              8            ⁢                                                  ⁢            s                                R            (                                                            2                  ⁢                                                                          ⁢                                      p                    /                    3                                                              +                              t_RTO                ×                                                      3                    ⁢                                                                                  ⁢                                          p                      /                      8                                                                      ×                p                ×                                  (                                      1                    +                                          32                      ⁢                                                                                          ⁢                                              p                        2                                                                              )                                                      )                                              (                  Equation          ⁢                                          ⁢          1                )            
In equation 1, “R” is the RTT, “p” is the loss event rate, “s” is the packet size and “t_RTO” is the timeout value used in TCP. 4Rs are generally used for t_RTO. Since R is the denominator of equation 1, it is obvious that the transmittable rate Xcal is inversely proportional to RTT and that the transmittable rate Xcal decreases as RTT increases.
As the scheme for delivering packets to a plurality of terminals as described above, the SICC scheme uses, for example, the XCAST scheme disclosed in Non-Patent Document 3.
The XCAST scheme disclosed in Non-Patent Document 3 is a scheme for explicitly specifying all receiving terminals to which the transmitting side delivers a packet by the transmitter by storing the destination addresses of all receiving terminals belonging to a predetermined group in the option header or payload in the packet. According to this XCAST scheme, when a relay router located between a transmitting node and a receiving node does not support the XCAST scheme, a packet delivered to the relay router is identified by the destination address and delivered to one receiving terminal to which no packet has been delivered yet. When there still remains a destination to which the packet has not been delivered yet, the receiving terminal having received the packet retransmits the packet to the destination to which the packet has not been delivered yet. When the receiving terminal repeats such relay operation, packets are delivered to all receiving terminals.
That is, even if the relay router does not support the XCAST scheme, a plurality of receiving terminals carry out concatenated transfer in the XCAST scheme, and the packet can thereby be delivered to the receiving terminals.    Non-Patent Document 1: E. Muramoto, et al., “Proposal for Congestion Control Method on Sender Initiated Multicast,” Internet Conference 2003    Non-Patent Document 2: M. Handley, et al., “TCP Friendly Rate Control (TFRC): Protocol Specification”, RFC 3448, January 2003    Non-Patent Document 3: Y. Imai, et al., “XCAST6: eXplicit Multicast on IPv6,” IEEE/IPSJ SAINT2003 Workshop 4, IPv6 and Applications, Orland, January 2003